-
Notifications
You must be signed in to change notification settings - Fork 3.4k
Update compiler-rt to llvm-12 #14280
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
8f6f87d
to
e3a88be
Compare
e3a88be
to
2045373
Compare
To see the diff from upstream you can use this like: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looking at the diff to upstream:
- Is the diff in
ubsan_checks.inc
necessary? - The diff in
ubsan_handlers.cpp
looks odd - no ifdefing for emscripten, just a pure change to upstream?
thrd_detach: 'pthread_detach', | ||
#endif |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
this could be on a single line like the {{{ }}}
stuff above.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I couldn't make it work when the string is on the right of the ":" for some reason. It was giving me JS compiler errors. Plus I think this syntax is more readable in the end.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
But it works just several lines above in the diff? I don't understand. It's just adding a prefix to a string, isn't it?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Somehow it works in the key position but not in the value position. Oh maybe its because the keys are not in quotes.. Let me try again.
These are part of the existing 10.0.0 changes. I don't really know why they were removed, but they were. Maybe something to do with the way emscripten handles NULL vs native platforms. See the existing 10.0.0 changes:
Again, these are just carried over from the current changes: We can look at cleaning them or and/removing as we look into upstreaming perhaps? |
Followup to #14280 Changes from upstream can be seen at: llvm/llvm-project@llvmorg-12.0.0...emscripten-core:emscripten-libs-12.0.0 Fixes: #14244
Followup to #14280 Changes from upstream can be seen at: llvm/llvm-project@llvmorg-12.0.0...emscripten-core:emscripten-libs-12.0.0 Fixes: #14244
Followup to #14280 Changes from upstream can be seen at: llvm/llvm-project@llvmorg-12.0.0...emscripten-core:emscripten-libs-12.0.0 Fixes: #14244
Followup to #14280 Changes from upstream can be seen at: llvm/llvm-project@llvmorg-12.0.0...emscripten-core:emscripten-libs-12.0.0 Fixes: #14244
It looks several asan/lsan tests started to break after this. Starting commit: https://ci.chromium.org/ui/p/emscripten-releases/builders/ci/linux-test-suites/b8846238787694172272/overview |
Ah yes dropped the ball on that.. thanks for reminding me. |
This test leaks allocates the asyncify stack during the exit handlers and its never freed. Interestingly enough this leak was not caught prior to #14280. I did some investigation and found that prior to #14280 this chunk was bring detected a reachable via the conservative stack scan here: https://github.com/emscripten-core/emscripten/blob/98a8cbf5032f8d369be636a59180a59f1eb8833f/system/lib/compiler-rt/lib/lsan/lsan_common_emscripten.cpp#L141-L153 If I comment out this stack scan then this leak will be detected even before #14280 Also, add `--profiling` to asan and lsan builds to make error reports more useful. See #14360
This test leaks allocates the asyncify stack during the exit handlers and its never freed. Interestingly enough this leak was not caught prior to #14280. I did some investigation and found that prior to #14280 this chunk was bring detected a reachable via the conservative stack scan here: https://github.com/emscripten-core/emscripten/blob/98a8cbf5032f8d369be636a59180a59f1eb8833f/system/lib/compiler-rt/lib/lsan/lsan_common_emscripten.cpp#L141-L153 If I comment out this stack scan then this leak will be detected even before #14280 Also, add `--profiling` to asan and lsan builds to make error reports more useful. See #14360
No description provided.